Subject: More DLUR Architecture Change Proposals Available For Review

From: "Ed Tremblay (254-5515)" <[email-masked]>
Date: Wed, 2 Aug 95 14:26:33 EDT

Proposals to change the APPN DLUR Architecture Reference manual have
been placed on networking.raleigh.ibm.com for items 8294, 8321, and
8322.  The files can be found in directory /aiw/dlur:

     abs8294.txt
     abs8321.txt
     abs8322.txt
     arch8294d.psbin (same as arch8303d.psbin; proposals are interrelated)
     arch8321d.psbin
     arch8322d.psbin

I'm requesting approval of these items at the next AIW this month during
the APPN Reference SIG session.

The individual items are as follows:

8294) Add DLUR processing to send PU name to DLUS

      Requirements from several vendors have been submitted to allow
      the DLUR to send a PU name to the DLUS to be used there.  Multiple
      reasons have been provided also, for example, to allow the end
      user to provide a PU name instead of the DLUS-generated name when
      the PU is dynamically created at the DLUS; and to provide the DLUS
      with additional PU search criteria when the DLUR and DLUS are
      adjacent and two PUs have been defined at the DLUS.

      The proposed solution is to add CV X'0E' type X'F1' (PU name)
      to the FID2 Encapsulation (X'1500') GDS variable when it
      encapsulates the REQACTPU RU to allow the DLUR to send the PU name
      to the DLUS (just as currently the DLUS uses the same CV on ACTPU
      to send the PU name to the DLUR).

      The PU name can be sent either with or without a NETID:

         * non-network qualified (without NETID) - in this case the
           DLUS will match only on PU name.

         * network qualified (with NETID) - in this case the DLUS will
           match on NETID.PUname.  It is an implementation option for
           the DLUR to choose how to get the PU name and the NETID to
           put together a network-qualified PU name to put in the
           CV X'0E'.  The DLUR could require the user to define a
           network-qualified PU name, or only define a PU name and use
           its own NETID, or in the case of a downstream PU learn about
           the NETID via XID (remember: a downstream PU could have a
           NETID different from the DLUR's NETID; it is the PU's NETID
           which will be included in the CV X'0E').

      In adding this function,

         - the DLUR will optionally include the PU name when sending a
           REQACTPU; it can send

              * PU name

              * PU name, XID

              * PU name, signaling information

              * PU name, XID, signaling information

              * XID

              * signaling information

              * XID, signaling information

           When both PU name and CP name are sent to the DLUS, these
           names must be different.

         - any signaling information received at the DLUS will be
           used for (in addition to PU correlation for internal PU)

              * network management

              * CSX user exit for connection verification and accounting

         - the DLUS will look for CV X'0E' upon receiving a REQACTPU;
           if the CV is present, the PU name will be used in the
           algorithm to search for a matching PU defined at the DLUS:

              * PU name - if the DLUR supplies a PU name and if it
                matches a predefined PU name, the search is over;
                otherwise,

              * IDBLK/IDNUM - if the DLUR supplies an IDBLK/IDNUM and it
                matches a predefined IDBLK/IDNUM, the search is over
                (note that the PU names may not match - the DLUR may
                accept the DLUS-provided name); otherwise,

              * CP name - if the DLUR supplies a CP name and it matches
                a predefined CP name, the search is over (note that the
                PU names may not match - the DLUR may accept the
                DLUS-provided name); otherwise,

              * user exit - if an exit exists, a dynamic PU will be
                created (note that the PU names may not match - the
                DLUR may accept the DLUS-provided name); otherwise, the
                search will fail

                   - if the DLUS detects a name conflict,

                       *  if a duplicate PU name is detected, the DLUS
                          will reject the REQACTPU with

                            X'0888 0016'   The DLUR-specified network
                                           name is known, but is a
                                           duplicate resource.

                       *  if a NETID mismatch is detected, the DLUS will
                          reject the REQACTPU with

                            X'0891 000A'   Invalid Network ID: the
                                           network ID in the Network
                                           Name control vector does not
                                           match the network ID of the
                                           target resource of the
                                           REQACTPU.

                   - if the PU name is unacceptable to the DLUS, it
                     will reject the REQACTPU with

                       X'080A 000F'   The request was rejected because
                                      of constraints or policies
                                      specific to the receiving DLUS.
                                      The request should not be retried.

         - if the DLUS cannot find a matching defined PU and a dynamic
           PU is created, it can use the PU name included in the
           REQACTPU

         - if the DLUR receives a PU name on ACTPU different from the
           name sent with the REQACTPU, it may accept the DLUS-provided
           PU name (see search order options below); this can occur,
           for example, when the DLUS does not recognize the PU name
           sent with the REQACTPU, and if other information is present,
           it can find a match based on IDBLK/IDNUM or CP name and
           return the name of the matching predefined PU

         - when a DLUR receives an ACTPU, the search order to find the
           correct PU is a product option:

           Option A - PU name does not have to match
           -----------------------------------------
           1) PU name - this name does not have to match a DLUR-defined
              name for the same PU, and the DLUS-provided PU name will
              be accepted

           2) CP name and/or IDBLK/IDNUM - whatever is received must
              match its corresponding definitions at the DLUR;
              otherwise, the ACTPU will be rejected (since the CP names
              and/or IDBLK/IDNUMs do not match)

           Option B - PU name must match
           -----------------------------
           1) PU name - if the DLUS supplies a PU name and if it matches
              a predefined PU name, the search is over; otherwise,

           2) IDBLK/IDNUM - if the DLUR supplies an IDBLK/IDNUM and it
              matches a predefined IDBLK/IDNUM, then

                a) if the predefined IDBLK/IDNUM has no PU name defined
                   with it, the search is over and the DLUS-supplied PU
                   name will be used; otherwise,

                b) if the predefined IDBLK/IDNUM has a PU name defined
                   with it, the ACTPU will be rejected (since the PU
                   names do not match);

              otherwise, the ACTPU will be rejected (since the
              IDBLK/IDNUMs do not match)

8321) Add DLUR/S processing for encapsulated FID2 segments on CP-SVR
      pipe to DLUS

      A requirement has been submitted by VTAM and CM/2 to support
      segmented FID2 PIUs for encapsulated data transmissions received
      over the CPSVRMGR pipe from the DLUR.  There are some messages
      which are encapsulated and sent on the CP-SVR pipe from the DLUR
      to the DLUS, for example, NMVTs, which can become so large that
      they exceed the storage available to hold them in a DLUR.  If a
      DLUR could segment these large messages, they could be sent and
      not be truncated or discarded.

      The proposal will allow the DLUR to segment a FID2 PIU and
      encapsulate the segments in separate GDS X'1500's.  The only PIUs
      which can be segmented are FMD requests, FMD responses with QRI=1,
      and non-expedited DFC requests.  The segments will be reassembled
      at the DLUS.

8322) Add DLUR segmentation support for short RSP(BIND) LUs

      Several products have raised concerns with the current DLUR WBRI
      processing for SLUs sending short RSP(BIND)s.  The DLUR and NCP
      both assume that such a SLU cannot handle segments (indicating
      WBRI set on).  However, when a PIU too large to be sent on the
      downstream link to the SLU is received, the DLUR will UNBIND the
      LU-LU session while the NCP will segment the message.

      This is a mismatch of function putting the DLUR at a disadvantage
      (even though it is doing the right thing).  For easier migration,
      the DLUR should follow the NCP's procedure.

      The proposed solution is based on the realizations that:

         1) For APPN, WBRI has meaning for a hop, not the LU itself.
            When DLUR sets WBRI, it is indicating its own ability to
            handle segments from the upstream hop, not the SLU's
            ability.

         2) When a SLU returns a short +RSP(BIND) for a BIND request
            whose max RU size exceeded the downstream link capability,
            one can infer an implied capability to accept segments at
            the SLU.  Detecting those conditions, a DLUR BF could send
            segments to the SLU.

         3) Some DLURs with memory constraints may be concerned that the
            whole PIU sent from the PLU may exceed their capacity to
            receive it.  With segmentation on the downstream link now
            allowed, the DLUR could set WBRI off and accept segments
            from the PLU but not reassemble them before sending anything
            to the SLU.  The DLUR could pass the segments on to the SLU,
            or if the PLU segment was too large for the link, break the
            PLU segment up into multiple segments and send them to the
            SLU.

      Therefore, it is proposed that the DLUR WBRI processing be
      updated with the following:

         * if WBRI is reserved, act as if DLUR received WBRI=0; if
           segments are received from the PLU, the DLUR can either:

              - reassemble the segments and attempt to send the whole
                message to the SLU (only if the DLUR supports segment
                reassembly); if the reassembled message is too
                large, the DLUR can segment the message and send the
                segments to the SLU

              - attempt to send the segments received from the PLU to
                the SLU; if a segment is too large, the DLUR can segment
                the PLU segment and send the new segments to the SLU

Ed Tremblay

---

From: "jim (j.) cobban" <[email-masked]>
Date: Thu, 3 Aug 1995 13:35:00 -0400

In message "More DLUR Architecture Change Proposals Available For Review", 

>8322) Add DLUR segmentation support for short RSP(BIND) LUs
...
>            PLU segment up into multiple segments and send them to the

There is a theoretical problem here.  In the PU 2 architecture there is an
option in which RU assembly is performed at the station level, rather than
at the session level.  If RU assembly is performed at the station level, then
it is not legal to intersperse PIUs which are part of different RUs on
different sessions.  This can never happen in the NCP BF because RUs are
always transported unsegmented through the subarea network if they originate
in a subarea node.  Therefore once the NCP BF starts segmenting a particular
RU it will never intersperse PIUs from another RU.  However with this
proposal a single DLUR could be receiving PIUs from multiple independent
PLUs, on independent sessions.  There is therefore no guarantee of the
relative ordering of PIUs.

I say this is a theoretical problem because I have never encountered a device
which actually failed when sent interspersed PIUs, however the architects
must have been aware of some such implementation or they would not have added
the additional complexity to the architecture.  If the link station does not
support XID, or responds with a format 0 XID there is no way to identify
whether it supports link-station assembly.  If a format 1 XID is returned
this capability is signalled in byte 9.  Any node sending a format 3 XID must
support session level assembly.

Jim Cobban   |  [email-masked]                        |  Phone: (613) 763-8013
BNR Ltd.     |  bnrgate.bnr.ca!bcars153!jcobban       |  FAX:   (613) 763-5199
|                                                                             |
|   The opinions expressed are those of the author and do not necessarily     |
|   represent the opinions of Bell-Northern Research or Northern Telecom.     |